feat(intl): Segments view mode — answer a grapheme loop without materialising a record or a substring - #9870

…ising nothing

v1 bound the segment with `_segment` once per step and left the body alone, so
it removed the record and kept the substring. v2 rewrites the USES: on a site
where the classifier found nothing that needs the string, the accepted path
materialises nothing at all and the loop reaches zero allocations per grapheme.

That is where the remaining time is. perry-b4's I2 table puts ink's wrapText
subtree at 80.2 % of active main-thread CPU (`E46`/`tI1` 4,238 of 5,152
samples, `u_N_24_6` 4,131 — about 4.1 s of a 5.2 s turn), with no dominant
collector leaf left; the collector's share is minors landing inside this loop.
v1 does not reach that. v2 does.

Two substitutions, with very different risk.

`O.codePointAt(k)` becomes `js_segments_view_code_point_at(cursor, k)` — a pure
expression swap. `k` is unchanged: it is segment-relative and segment-bounded
by the runtime's contract (§9d), the same bound the materialised substring had.

`recv.test(O)` is the hard one. Read from PerryTS#9870 rather than assumed:
`js_segments_view_regexp_test(cursor, regex)` — CURSOR FIRST — returns true,
false, or `undefined` meaning "I declined" (global/sticky regex, patched
`RegExp.prototype.test` or an own `test`), and the runtime does NOT fall back
internally, so the compiler must. `recv` is arbitrary — in cc it is
`g54.default()`, an opaque call that must run exactly once per evaluation — so
it cannot be repeated in the fallback arm. The emitted form is a pure
expression, so no control flow is restructured:

    Sequence([ LocalSet(t_recv, <recv>),                     // opaque call, ONCE
               LocalSet(t_res, _regexp_test(cursor, t_recv)),
               t_res === undefined ? t_recv.test(_segment(cursor)) : t_res ])

The materialisation is inside the decline arm, so the accepted path allocates
nothing.

Every rewritten use is GUARDED, not replaced: `cur != 0 ? <view form> :
<original>`. The loop body is shared between the accepted and declined paths,
so the original expression must survive for the decline arm, where `O` holds a
real string. On acceptance `O` is bound to `undefined` and never read, because
every use takes the view arm — which is what makes the accepted path
allocation-free without duplicating the body.

A site with even one unanswerable use stays on v1: paying per-use guards on top
of a materialisation that happens anyway is strictly worse.

WHAT SUBSTITUTES FOR THE TESTS THIS COULD NOT BE RUN AGAINST. This box cannot
build (its target was deleted to recover disk), so `rustfmt` and reading are
the only gates. The pass therefore rewrites a CLONE of the body and keeps it
only if the emission matches the classification exactly — same `code_point_at`
count, same `regexp_test` count. If they disagree, some use was not rewritten
and would read an unbound segment on the accepted path, so the clone is
discarded and v1 is used. The check is the mechanism, not a comment.

`[segview-lower]` now reports which arm was taken, so classifier and emission
can be compared on the real bundle:

    [segview-lower] <rec> open=1 next=1 segment=0 code_point_at=1 regexp_test=2 declined=none (v2: …)
    [segview-lower] <rec> open=1 next=1 segment=1 code_point_at=0 regexp_test=0 declined=none (v1: …)

Decline paths are unchanged. Three HIR-level tests added beside the v1 ones.

NOT COMPILED AND NOT RUN — see the commit message above and §v2 of
HANDOFF_segview_e2e.md for exactly what is unverified.

Claude-Session: https://claude.ai/code/session_014knX724SYDogwzsXybCGxp

…ising nothing

v1 bound the segment with `_segment` once per step and left the body alone, so
it removed the record and kept the substring. v2 rewrites the USES: on a site
where the classifier found nothing that needs the string, the accepted path
materialises nothing at all and the loop reaches zero allocations per grapheme.

That is where the remaining time is. perry-b4's I2 table puts ink's wrapText
subtree at 80.2 % of active main-thread CPU (`E46`/`tI1` 4,238 of 5,152
samples, `u_N_24_6` 4,131 — about 4.1 s of a 5.2 s turn), with no dominant
collector leaf left; the collector's share is minors landing inside this loop.
v1 does not reach that. v2 does.

Two substitutions, with very different risk.

`O.codePointAt(k)` becomes `js_segments_view_code_point_at(cursor, k)` — a pure
expression swap. `k` is unchanged: it is segment-relative and segment-bounded
by the runtime's contract (§9d), the same bound the materialised substring had.

`recv.test(O)` is the hard one. Read from PerryTS#9870 rather than assumed:
`js_segments_view_regexp_test(cursor, regex)` — CURSOR FIRST — returns true,
false, or `undefined` meaning "I declined" (global/sticky regex, patched
`RegExp.prototype.test` or an own `test`), and the runtime does NOT fall back
internally, so the compiler must. `recv` is arbitrary — in cc it is
`g54.default()`, an opaque call that must run exactly once per evaluation — so
it cannot be repeated in the fallback arm. The emitted form is a pure
expression, so no control flow is restructured:

    Sequence([ LocalSet(t_recv, <recv>),                     // opaque call, ONCE
               LocalSet(t_res, _regexp_test(cursor, t_recv)),
               t_res === undefined ? t_recv.test(_segment(cursor)) : t_res ])

The materialisation is inside the decline arm, so the accepted path allocates
nothing.

Every rewritten use is GUARDED, not replaced: `cur != 0 ? <view form> :
<original>`. The loop body is shared between the accepted and declined paths,
so the original expression must survive for the decline arm, where `O` holds a
real string. On acceptance `O` is bound to `undefined` and never read, because
every use takes the view arm — which is what makes the accepted path
allocation-free without duplicating the body.

A site with even one unanswerable use stays on v1: paying per-use guards on top
of a materialisation that happens anyway is strictly worse.

WHAT SUBSTITUTES FOR THE TESTS THIS COULD NOT BE RUN AGAINST. This box cannot
build (its target was deleted to recover disk), so `rustfmt` and reading are
the only gates. The pass therefore rewrites a CLONE of the body and keeps it
only if the emission matches the classification exactly — same `code_point_at`
count, same `regexp_test` count. If they disagree, some use was not rewritten
and would read an unbound segment on the accepted path, so the clone is
discarded and v1 is used. The check is the mechanism, not a comment.

`[segview-lower]` now reports which arm was taken, so classifier and emission
can be compared on the real bundle:

    [segview-lower] <rec> open=1 next=1 segment=0 code_point_at=1 regexp_test=2 declined=none (v2: …)
    [segview-lower] <rec> open=1 next=1 segment=1 code_point_at=0 regexp_test=0 declined=none (v1: …)

Decline paths are unchanged. Three HIR-level tests added beside the v1 ones.

NOT COMPILED AND NOT RUN — see the commit message above and §v2 of
HANDOFF_segview_e2e.md for exactly what is unverified.

Claude-Session: https://claude.ai/code/session_014knX724SYDogwzsXybCGxp

…ew-mode regex path

#9870 inserted `regexp_test_str_bounded` between `js_regexp_test` and its
own `#[cfg(feature = "regex-engine")]` + `#[no_mangle]`, so both attributes
silently re-targeted onto the new function. Two consequences, neither
visible to a workspace build (feature unification turns the engine on):
`js_regexp_test` lost its gate and failed to compile without the engine,
and a `pub(crate)` Rust fn picked up a `#[no_mangle]` it must not have.
Attributes reattached to the function each belongs to.

`js_segments_view_regexp_test` reaches two engine-gated helpers. It is
`#[no_mangle]`, so it cannot itself be gated out — the symbol has to exist
in every configuration or a binary emitting a call fails to link. Its
regex-dependent path is gated instead, and the engine-off arm declines,
which is the same contract its other declines already have.

Also classifies #9870's eight new PERRY_SEGVIEW_DIAG counters as
not_a_gc_pointer: plain AtomicU64 tallies written only via fetch_add.

…ising nothing

v1 bound the segment with `_segment` once per step and left the body alone, so
it removed the record and kept the substring. v2 rewrites the USES: on a site
where the classifier found nothing that needs the string, the accepted path
materialises nothing at all and the loop reaches zero allocations per grapheme.

That is where the remaining time is. perry-b4's I2 table puts ink's wrapText
subtree at 80.2 % of active main-thread CPU (`E46`/`tI1` 4,238 of 5,152
samples, `u_N_24_6` 4,131 — about 4.1 s of a 5.2 s turn), with no dominant
collector leaf left; the collector's share is minors landing inside this loop.
v1 does not reach that. v2 does.

Two substitutions, with very different risk.

`O.codePointAt(k)` becomes `js_segments_view_code_point_at(cursor, k)` — a pure
expression swap. `k` is unchanged: it is segment-relative and segment-bounded
by the runtime's contract (§9d), the same bound the materialised substring had.

`recv.test(O)` is the hard one. Read from PerryTS#9870 rather than assumed:
`js_segments_view_regexp_test(cursor, regex)` — CURSOR FIRST — returns true,
false, or `undefined` meaning "I declined" (global/sticky regex, patched
`RegExp.prototype.test` or an own `test`), and the runtime does NOT fall back
internally, so the compiler must. `recv` is arbitrary — in cc it is
`g54.default()`, an opaque call that must run exactly once per evaluation — so
it cannot be repeated in the fallback arm. The emitted form is a pure
expression, so no control flow is restructured:

    Sequence([ LocalSet(t_recv, <recv>),                     // opaque call, ONCE
               LocalSet(t_res, _regexp_test(cursor, t_recv)),
               t_res === undefined ? t_recv.test(_segment(cursor)) : t_res ])

The materialisation is inside the decline arm, so the accepted path allocates
nothing.

Every rewritten use is GUARDED, not replaced: `cur != 0 ? <view form> :
<original>`. The loop body is shared between the accepted and declined paths,
so the original expression must survive for the decline arm, where `O` holds a
real string. On acceptance `O` is bound to `undefined` and never read, because
every use takes the view arm — which is what makes the accepted path
allocation-free without duplicating the body.

A site with even one unanswerable use stays on v1: paying per-use guards on top
of a materialisation that happens anyway is strictly worse.

WHAT SUBSTITUTES FOR THE TESTS THIS COULD NOT BE RUN AGAINST. This box cannot
build (its target was deleted to recover disk), so `rustfmt` and reading are
the only gates. The pass therefore rewrites a CLONE of the body and keeps it
only if the emission matches the classification exactly — same `code_point_at`
count, same `regexp_test` count. If they disagree, some use was not rewritten
and would read an unbound segment on the accepted path, so the clone is
discarded and v1 is used. The check is the mechanism, not a comment.

`[segview-lower]` now reports which arm was taken, so classifier and emission
can be compared on the real bundle:

    [segview-lower] <rec> open=1 next=1 segment=0 code_point_at=1 regexp_test=2 declined=none (v2: …)
    [segview-lower] <rec> open=1 next=1 segment=1 code_point_at=0 regexp_test=0 declined=none (v1: …)

Decline paths are unchanged. Three HIR-level tests added beside the v1 ones.

NOT COMPILED AND NOT RUN — see the commit message above and §v2 of
HANDOFF_segview_e2e.md for exactly what is unverified.

Claude-Session: https://claude.ai/code/session_014knX724SYDogwzsXybCGxp

…ising nothing

v1 bound the segment with `_segment` once per step and left the body alone, so
it removed the record and kept the substring. v2 rewrites the USES: on a site
where the classifier found nothing that needs the string, the accepted path
materialises nothing at all and the loop reaches zero allocations per grapheme.

That is where the remaining time is. perry-b4's I2 table puts ink's wrapText
subtree at 80.2 % of active main-thread CPU (`E46`/`tI1` 4,238 of 5,152
samples, `u_N_24_6` 4,131 — about 4.1 s of a 5.2 s turn), with no dominant
collector leaf left; the collector's share is minors landing inside this loop.
v1 does not reach that. v2 does.

Two substitutions, with very different risk.

`O.codePointAt(k)` becomes `js_segments_view_code_point_at(cursor, k)` — a pure
expression swap. `k` is unchanged: it is segment-relative and segment-bounded
by the runtime's contract (§9d), the same bound the materialised substring had.

`recv.test(O)` is the hard one. Read from #9870 rather than assumed:
`js_segments_view_regexp_test(cursor, regex)` — CURSOR FIRST — returns true,
false, or `undefined` meaning "I declined" (global/sticky regex, patched
`RegExp.prototype.test` or an own `test`), and the runtime does NOT fall back
internally, so the compiler must. `recv` is arbitrary — in cc it is
`g54.default()`, an opaque call that must run exactly once per evaluation — so
it cannot be repeated in the fallback arm. The emitted form is a pure
expression, so no control flow is restructured:

    Sequence([ LocalSet(t_recv, <recv>),                     // opaque call, ONCE
               LocalSet(t_res, _regexp_test(cursor, t_recv)),
               t_res === undefined ? t_recv.test(_segment(cursor)) : t_res ])

The materialisation is inside the decline arm, so the accepted path allocates
nothing.

Every rewritten use is GUARDED, not replaced: `cur != 0 ? <view form> :
<original>`. The loop body is shared between the accepted and declined paths,
so the original expression must survive for the decline arm, where `O` holds a
real string. On acceptance `O` is bound to `undefined` and never read, because
every use takes the view arm — which is what makes the accepted path
allocation-free without duplicating the body.

A site with even one unanswerable use stays on v1: paying per-use guards on top
of a materialisation that happens anyway is strictly worse.

WHAT SUBSTITUTES FOR THE TESTS THIS COULD NOT BE RUN AGAINST. This box cannot
build (its target was deleted to recover disk), so `rustfmt` and reading are
the only gates. The pass therefore rewrites a CLONE of the body and keeps it
only if the emission matches the classification exactly — same `code_point_at`
count, same `regexp_test` count. If they disagree, some use was not rewritten
and would read an unbound segment on the accepted path, so the clone is
discarded and v1 is used. The check is the mechanism, not a comment.

`[segview-lower]` now reports which arm was taken, so classifier and emission
can be compared on the real bundle:

    [segview-lower] <rec> open=1 next=1 segment=0 code_point_at=1 regexp_test=2 declined=none (v2: …)
    [segview-lower] <rec> open=1 next=1 segment=1 code_point_at=0 regexp_test=0 declined=none (v1: …)

Decline paths are unchanged. Three HIR-level tests added beside the v1 ones.

NOT COMPILED AND NOT RUN — see the commit message above and §v2 of
HANDOFF_segview_e2e.md for exactly what is unverified.

Claude-Session: https://claude.ai/code/session_014knX724SYDogwzsXybCGxp
(cherry picked from commit 089cb3b)